iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 29
0
自我挑戰組

開源組織生態觀察筆記系列 第 29

[Day29] Git & GitHub & GitHub Flow

  • 分享至 

  • xImage
  •  

git 可謂現在工程師不可不知的生產力工具,不過今天只會提到 git 的線上教學資源,然而這篇要介紹的是 GitHub Flow。

Git & GitHub

關於 git

git 是一套分散式版本控制系統,是為了更好管理Linux內核而開發的,現在也是多數工程師開發專案會用的一項版本控管工具。
如果想學的,就到以下連結學學看吧!

關於 GitHub

GitHub 是一個免費提供 Git Server 的圖形介面管理平台,也稱為全球最大的工程師社群交友平台(笑),會有此暱稱也不是玩笑話,基本上多數的開源專案都是透過 GitHub 進行開發管理、維護、溝通,雖然現在 GitHub 被微軟收購後很多專案都移動到 GitLab 了(笑)

GitHub 除了是 Git Server,上文提到「開發管理、維護、溝通」就是下段要說的 GitHub Flow,也是參與開源專案的重中之重。

GitHub Flow

再講 GitHub Flow 前要先介紹簡單提一下 Git Flow,請見以下

Git Flow

  1. clone
  2. checkout & branch
  3. add
  4. commit
  5. push

基礎的四個步驟涵括開分支、新增/修改檔案、提交到本地 repo、上傳到遠端
然而 GitHub Flow 則是大概長這樣

GitHub Flow

  1. Issue
  2. fork
  3. clone
  4. checkout & branch
  5. add
  6. commit
  7. push
  8. Pull Requests(PRs)
  9. Review
  10. Merge

第零步驟稍後在說,而第一個步驟是複製一個想要貢獻的專案到自己的名下,然後步驟 2-6 就是單純的 Git Flow,根據要修改的 Bug 或是要開發的功能開分支進行修改(一般來說不會在 master 分支進行修改),最後推到自己在 GitHub 上面的專案,然後將這個修改送回原始專案,經過專案維護者的審核,有可能會進行修改,修改完都沒問題就完成 Merge。

開源貢獻之 Issue

當你要進行開源貢獻之前,最重要的事情不是直接開發,而是搞清楚狀況!怎麼說呢?一個專案的貢獻者很多,如果大家都沒經過溝通就著手開發,很容易就導致「重造輪子」的問題,而且 GitHub 上的紀錄就是累積工程師貢獻的證明,如果沒有好好管理,只怕有新的人想貢獻都難,因此首先來認識一下 Issue 的作用

Issue 用途與注意事項

  • 用來詢問 bug
  • 詢問是否可以開發某項功能
  • 討論問題(這個不一定,因為有些專案有類似 IRC 可以即時溝通的地方)
  • 追蹤 bug 與 Feature

Issue explore

當你對某個功能有疑問,或是想開發新的功能,善用搜尋的功能是一個好習慣,請看圖例

在 filter 的地方輸入關鍵字,或是可以學習一下 tag 搜尋法

開源貢獻之 PRs 與 Review

PRs 雖然是最後的步驟,不過其實送出 PRs 後的 Review 是相當重要的,另外也可以透過

跟上文一樣透過搜尋來鎖定可能正在開發的功能

PRs 說明與注意事項

  • 根據自己修改的程式碼申請送回原始專案
  • 不一定會被 merge 喔!
  • 請注意 coding style!
  • 請先閱讀 CONTRIBUTED.md(一般來說都會有,而且必看!)

Review

  • 專案維護者通常會指定人選來進行 Review
  • Review 也算是貢獻的一環,會在你的活動紀錄算上一筆
  • 介面其實跟 issue 討論很像,不過可以針對你修改的程式碼提出引用,並且逐行審核,超棒的!

結語

這篇文章就是鐵人賽的最後一篇產出,明天的內容會寫些心得,並統整 30 天的文章,謝謝你的觀賞~


上一篇
[Day28] 開源參與 --- 文件/軟體翻譯
下一篇
[Day30] 結尾
系列文
開源組織生態觀察筆記30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言